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ABSTRACT 


The ability to statically determine what kinds of packets can be exchanged 
between two hosts on a network is desirable to those who design and operate 
networks, but this is a difficult and complex problem. Factors affecting 
reachability analysis are packet filters, routing policies and packet 
transformations. The number of variables within and among networks is 
intractable for manual computation. A proposed solution to this mess is a 
tractable framework for which to map networks into, thus creating a single unified 
model for analysis. It depends heavily on the use of transforming the problem 
into a classical graph problem that can be solved with polynomial time algorithms 
such as transitive closure. 

This research develops an automated validation process to test the 
reachability upper bound calculated from a recent implementation of the 
framework which focuses specifically on the packet filter aspect, namely access 
control lists. Real-world network configuration files and network packet flow data 
from a Tier-1 Internet Service Provider is supplied as the data set. A significant 
contribution of this thesis is the application of real-world data to the proposed 
method for static reachability analysis as it pertains to the static testing of 
security policies applied via packet filters. 
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I. INTRODUCTION 


The concept of a network dates back to primitive society where smoke 
signals, fire towers, and symbols viewed by spyglass were used to communicate 
and share information [1]. This basic idea of being able to reach others via an 
indirectly connected mechanism (be it physical or logical) is manifested by the 
complex computer networks commonly found today. They are now critical 
systems supporting a multitude of applications depended upon by businesses, 
governments, educational and private sectors. At their core is the premise of 


reachability between hosts. 


Network reachability analysis is focused on identifying what types of 
packets are able to traverse between two hosts on a network beyond that of 
physical connectivity, network topology and routing protocols. It is subject to 
policies that are set in place for reasons such as security, network control, and 
licensing agreements, which in turn levy constraints on network design and 
restrict the number of destinations with which hosts are permitted to 
communicate. This poses a significant challenge for network designers who 


must properly fulfill security policy requirements. 


Implementation of policy objectives involves three general methods — 
packet filters, routing policies and packet transformations — each has an affect on 
reachability and thus must be taken into consideration [2]. Determining 
reachability can thus become quite difficult. The problem is even further 


exacerbated by the size and complexity of the network itself. 


Critical to the network’s reliability is how faithfully the network design 
implements security policy. Identification of vulnerabilities in policy can be quite 
challenging. Given a scenario where a communication failure exists between two 
hosts, troubleshooting efforts may first seek to investigate the connectivity 
between them only to find that it remains intact. The next logical approach is to 


explore the network configuration for design or implementation flaws. 


Attempted solutions to the problem are limited. Current practices of 
determining network reachability rely on_ real-time, intrusive, manual 
troubleshooting methods. Tools such as ping and traceroute send probe traffic 
over the network which in turn must be analyzed by hand through poring over the 
network configuration. Consider that campus, enterprise and backbone networks 
range from 5 to upwards of 1,000 routers, manual calculation is quite impractical 
[2]. Other tools analyze the flow of packets over a network (dynamic analysis) 
but require direct access to live networks working in real-time in order to monitor 
behavior [3]. They do not consider all of the potential packets that could traverse 
the network between hosts. 


The benefits and practicality of an automated, static, non-intrusive method 
for reachability analysis have only recently been researched. This thesis focuses 
on the validation of a current implementation which analyzes packet filters in 
particular. It is based on the seminal research described in On Static 
Reachability Analysis of IP Networks conducted by Xie, et al., where a common 
framework is introduced to address three aspects of static reachability: packet 


filters, routing information and packet transformations. 


A. OBJECTIVE 

It is highly desirable to be able to statically determine what kinds of 
packets can be exchanged between two hosts on a network, however, this is 
difficult to do. The problem of reachability analysis must take into account more 
than routing protocols and topology. It must also consider packet filters, routing 
policies and packet transformations within that determination. Naturally, this is a 
difficult and complex problem for those who design and operate networks. The 
number of variables involved in a network and amongst networks can seem 
intractable and is simply too large for manual computation. An attempt at solving 
this mess is to develop a tractable framework for which to map networks into, 
thus creating a single unified model for analysis. It depends heavily on the use of 
transforming the problem into a classical graph problem that can be solved with 


polynomial time algorithms such as transitive closure [2]. 
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This research attempts to validate the upper bound reachability results 
calculated from a recent implementation of the framework [4] which focuses on 
the packet filter aspect in particular, namely access control lists (ACLs). Real- 
world network configuration files as well as network packet flow data from a tier-1 
Internet Service Provider (ISP) is supplied as the data set. A significant 
contribution of this thesis is the application of real-world data to the proposed 
method for static reachability analysis as it pertains to the static testing of 
security policies applied in part via packet filters (/.e., ACLs). 


B. BENEFITS OF STATIC ANALYSIS 

Static analysis uses a white-box approach where at any given time a 
snapshot of the network’s router configuration files is taken and then parsed into 
the framework thus serving as the source of information regarding the network 
under analysis. In this way, analysis can be conducted without direct interaction 
with the network itself and all of the critical reachability information regarding 


packet filters, routing policies and packet transformations is easily obtained. 


Given that the network description can be gathered from the router 
configuration files, it is possible to test reachability independently. By turning the 
focus away from analysis on the live networks, which is done on a single IP 
basis, more thorough analysis can be conducted through identification of IP 
ranges via static analysis. Tools such as ping and traceroute are limited in that 
they test the specific probe traffic sent between only two hosts and according to 
the path designated by routing protocols. Rather, static analysis enables the 
determination of all potential packet sets that could traverse the network between 
two points as well as those routers and hosts a given packet set could reach 


regardless of what routing protocols dictate. 


Validation of network design and security policies is another advantage of 
static reachability analysis. It can aide in meeting design goals of new networks 
prior to operational deployment or even before construction of the physical 
network. Additionally, static analysis provides the ability to conduct “what if” 
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scenarios on a network’s reachability. This reduces the risk of disruption to live 
networks by predicting the impact of hardware failures, configuration changes, 


and maintenance schedules. 


C. RESEARCH QUESTIONS 

Is the recent automated static reachability analysis implementation [4], 
which focuses particularly on the packet filters (e.g. ACLs) aspect of the 
framework described in [2], valid when tested against known tier-1 ISP network 
packet flows? 


a. Is it a viable suitable solution to validating security policies? 


b. What improvements are necessary? 


D. ORGANIZATION 

In Chapter Il, a background description of the current tool is provided to 
include its methodology. Chapter III delves into the validation method design and 
computation. It also explains the general characteristics of the ISP data sets 
used for validation and assumptions made. Chapter IV explains modifications 
made to the initial program source code as well as the development of new code. 
The limitations and bottlenecks discovered during the process are also noted as 
the validation results are reviewed. Lastly, Chapter V concludes the research 


and makes some recommendations for future work. 


ll. BACKGROUND 


The framework described in [2] is a critical component of the logic 
implemented in the program developed to conduct static reachability analysis [4] 
upon which was the subject of validation and research for this thesis. As such, a 
brief introduction is necessary for the reader to better understand the concepts 
involved. Thereafter will be a description of the methodology and design of the 
program titled Static Reachability Analysis (SRA) Toolkit [4] used to compute the 
reachability upper bound for each router pair. The data set used for validation will 


conclude this chapter. 


A. STATIC REACHABILITY ANALYSIS FRAMEWORK MODEL 

The authors of [2] have developed a tractable framework for which to map 
networks into, thus creating a single unified model for analysis. It depends 
heavily on the use of transforming varying views of a network into a classical 
single graph problem that can be solved with polynomial time algorithms such as 
transitive closure [5], [6]. The graph accounts for packet filters (routers and 
links), routing policy (route redistribution) and packet transformations (virtual 
node-edge pair) as nodes where reachability is an edge metric. They formally 
define the graph G = (V, E, F) where V is the set of routers, E is the set of 


connecting edges, and F is an edge labeling function. For each edge (u,v) € E, 


F € F represents the policies controlling the flow of packets between interfaces 


U,U 


wu and v or in reachability terms F represents the set of packets that the 


network is able to carry between two nodes. In the case of this research, 


f,, "epresents a packet filter containing predicates which challenge the properties 


of packet p to determine if it belongs in the set F’ , [2]. 


1. Formal Definition of Reachability Upper Bound 

The most important computation for this research is the reachability upper 
bound (RUB) between a source and destination router, but unless they are 
directly connected there must be intermediate routers or multiple hops. Thus, the 
reachability for each intermediate hop represents a subset of packets that the 
network will allow between two routers 1 and j, denoted as R,,, over edge u 
and v since clearly not all packets traversing between them originated from a 


single source router. Since ACLs are applied per interface, the edge wu and v 


represents the outbound and inbound interface respectively. 


Routing protocols, link failures, and changes in routing advertisements 
have an affect on R,,. Each router has a mechanism called its Forwarding 
Information Base (FIB) by which it can inform others of changes and updates to 
the interfaces that should be used for sending packets. This is called a router’s 
forwarding state, denoted by s. The set of all forwarding states for the entire 


network is denoted by S. The RUB, RY 


tj? 


represents the set of packets that 


could potentially flow from i to j given that all possible changes in forwarding 


state were properly made by the FIBs . It is formally defined as: 


ee = U R, (3) 


ses 


2. Reachability Upper Bound Calculation 

Computation of the RUB applies the basic mathematical concepts such as 
transitive closure [5] and shortest path algorithms [6]. The following algorithm is 
used to calculate Re, from source router z to destination router 7 that take up to 
m hops over the set of routers Vv. For each hop, intermediate calculations in 


reachability are represented by R' (i, 3) which consider the packet filter rules at 


each intermediary router k. Step 6 applies transitive closure of each R' (i, 3). 


po 
. 








Initialize R(i, j) to Bop -tow- all ay 


2. for (m = 1 to |v||-— 2) do 
34. for (i-= a. ‘toe.||y|/)> de 
4. R'(i, j) = ©; 
5. for (k =1to |||) do 
Ge tf (<5 Se BE) 
then RY (2,5) S/R (3) OF, TR (ee he 
Te “Rp aR (ay a) 9 


B. METHODOLOGY AND DESIGN OF THE STATIC REACHABILITY 
ANALYSIS TOOL 


The tool developed by [4] is an implementation of the static analysis 
concepts and algorithms previously discussed for computing the reachability 
upper bound of a network. This thesis research made a closer inspection of the 
tool as it performed against a real-world tier-1 ISP data set. Thus, an explanation 
of the methodology and design of the tool as to its handling of packet filters, data 


structures, and operations for reachability computation is in order. 


1 The PacketSet Data Structure 

The PacketSet data structure represents a packet filter (ACL) using a 5- 
tuple set notation. The value of each dimension is a range of the values (lower to 
upper) that are effectively permitted by each rule in the ACL. Additionally, unlike 
packet filters where each rule must be challenged sequentially in the order which 
they are listed, the PacketSet data structure eliminates this requirement. This is 
accomplished by mapping all permit and deny packet filter rules into the 5-tuple 
permit-only PacketSet data structure. Each 5-tuple is denoted using the 


following set notation: 





[SEC-Lpiowed cy SEC Lpiopes |F (Source IP Address) 
[Src-—portiower ¢ SLC —POLrtupper | } (Source Port Number) 
[dest-1piower , GAeSt-LPupper] 7 (Destination IP Address) 
[ ( 

[ ( 

















dest—portiower , Gdest-—portupper] 7 Destination Port Number) 
PLOtiower ¢ PLOCupper] Protocol Number) 








2. Creation of 


a PacketSet 


After a router configuration file is parsed, each of the packet filter rules 


composing a single ACL are processed into one PacketSet data structure. The 


algorithm handles each rule sequentially. All permit rules are placed into a buffer 


until a deny rule is encountered, which is then placed into a separate buffer. 


Each subsequent permit rule is then checked against every preceding rule in the 


deny buffer. This invokes the GetPermitTuple function to map permit and deny 


rules into a new permit-only tuple. Each comparison will result in the creation of 


zero, one, or two new tuples based on the following scenarios: 


0) The range of values in the permit rule is a subset of the deny rule’s 


1) Only one end (upper or lower range) of the permit and deny overlap 


2) The range of values in the deny rule is a subset of the permit rule’s 


Note that given ad 


-dimension tuple, the most that can be created is 2d. 


Creation of a PackSet data structure algorithm: 


1. Crea 
Crea 
For 


te empty PacketSet,; 
te an empty Deny Buffer; 





(each rule in ACL), do 














te an empty Interim Buffer; 


Convert rule into a new Current Tuple; 


2 

St 

4. Crea 
5 

6 


If r 





N“ 





ule is “Deny”, 





add Current Tuple to Deny Buffer; 


Else 


For 
For 


row @® + 


Add 





WN 


if rule is “Permit” 














Add Current Tuple to Interim Buffer; 





(j=0 to size of Deny Buffer), do 
(k=0 to size of Interim Buffer), do 

















Perform a GetPermitTuple on Interim 
Buffer[k] against Deny Buffer[]jl; 





Interim Buffer to PacketSet; 





If PacketSet is not empty, perform 








optimization to merge and remove overlapping 
ranges; 


In terms of mathematical notation, consider the following simple case 


involving only a two dimensional tuple (Although integers are used in the 


examples, for demonstrational purposes the first tuple could represent the source 


IP address range and the 


second tuple the source port number range): 
8 


For deny rule A and permit rule B: 


[ (A, 1) lowers (A, 1) upper ] r [ (A, 2) lowers (A, 2) upper | 








[ (B, 1) lowers (B, 1) upper | r [ (B, Zz) lowers (B, Zi) upper | 


Example 
[39,62]; [42,59] 


[37,68]; [25,81] 


Each comparison seeks the nearest value outside of the bounds of the deny 


rule range per dimension: 


[CB 1) lower, min{ (A, 1) lower = Lit 
[ (B, 2) lower, (B, 2) upper] U 


[max{(B,1) lower, (A, 1) upper + 1}, 
[ (B, 2) 1ower, (B, 2) upper] U 


[(B, 1) lower, (B, 1) upper] ; 
[(B, 2) lower, minf (A, 2) lower = dy 





[(B,1) lower, (B, 1) upper] ; 
[max{ (B, 2) lower, (A, 2) upper + lg a 





(B, 1) upper} ] ; 





(B, 1) upper] ; 


(B, 2) upper} ] U 


(B, 2) upper ] 





37,38]; 
25,81] U 


63,68]; 
25,81] U 


37,68]; 
25,47) VU 


37,68]; 
60, 81] 








The PacketSet data structure is extensible in that the emergence of a 


pattern appears given an increase in the number of dimensions. Overlapping 


tuple ranges can occur and thus an optimization function is necessary to 


compensate. The optimized pattern takes the following form: 








[2nd-D permit range]; .. ; 





[overlapping l1st-D range]; 








[3rd-D permit range]; .. ; 


[overlapping lst-D range]; 














[4th-D permit range]; .. ; 


[non-overlapping lst-D permit range]; 





[xth-D permit range] 


[non-overlapping 2nd-D permit range]; 





[xth-D permit range] 











[overlapping 2nd-D range]; 
[non-overlapping 3rd-D permit range]; 


[xth-D permit range] 


Once the ACLs are successfully mapped into PacketSet data structures, 


the burden of sequential rule processing for each permit and deny rule is 


relieved. Set operations can then be easily performed to conduct static 


reachability analysis. 


3: Reachability Upper Bound Computation 

After the packet filters are properly accounted for by the PacketSet data 
structure, the reachability computation can then be conducted. However, since 
only router configuration files are used as the source of network information it is 
necessary to estimate network topology. This is done using a simple neighbor 
discovery based on the IP address and mask assigned to each interface. Those 
network prefixes that match between interfaces on varying routers are thus 
considered to be connected. The reachability algorithm can now traverse the 


network. 


The tool uses an adaptation of the framework algorithm [2] to incorporate 


the PacketSet data structure. An algorithm is used to determine F, ,, the set of 
packets permitted over an edge (i, j) based on the ACLs encountered on each 


interface (u,v) respectively. 


For (each edge <i, j> in network) do 

Initialize Fi,j to empty PacketSet; 

For (each physical link <u,v>) do 

Obtain all the ACLs activated by outbound 

queue of u; 

5. PacketSet Sl = Intersection of all PacketSets 
specified by the ACLs obtained at step 4; 

6. Obtain all the ACLs activated by inbound 

queue of v; 








BwWN EF 




















7. PacketSet S2 = Intersection of all PacketSets 
specified by the ACLs obtained at step 6; 
8. =F, U(SINS2) 


The next algorithm first determines the reachability from all sources given 
a single destination j, then it returns the RUB calculation based on the specified 


source router i as new PacketSet. 
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1. Initialize packetSetRUB[i][j] for all i: 
to Fi,j if i and j are neighbors; 
to whole PacketSet, if i=j; 
to empty PacketSet, otherwise; 
for ( m=0 to (numberOfRouters — 3) ) do 
for ( i=0 to (numberOfRouters - 1) ) do 
tempPacketSetRUB[i][j] = empty; 
for (each interface (z) on router i) do 
for ( k=0 to numberOfRouters - 1 ) do 
if (k has an interface that is a 
neighbor of i on interface z) 
3... intersectedPacketSetRUB = 
Fi,k [|] packetSetRUB[k] [3]; 
9, tempPacketSetRUB[i][j] = 
tempPacketSetRUB[i][j] U 
intersectedPacketSetRUB ; 
10. endif; 
endloop; 
12. packetSetRUB[i] [Jj] = TempPacketSetRUB[i] [Jj]; 
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be 





It is important to note that only packet filters are considered as the focus of 
research, thus the effect that a routing protocol might have on forwarding packets 
to neighbors is not. Rather, all permitted packet sets from a router are assumed 
to reach all of its neighbors. 


C. NETFLOW DATA SET 

The data set used for the validation of the computed reachability upper 
bound is referred to as NetFlow data. It is a Cisco Internet Operating System 
technology that collects information on actual packet flows traversing the network 
as it enters specified routers. Each router identifies a flow by unique 
characteristics, such as IP address and application, and caches the accumulated 
data until the flow is completed. [7] 


Flow collection is not exhaustive however due to the resources that would 
be required for collection, processing and storage of the data. In order to control 
the amount of data collected, a technique called smart sampling preferentially 
samples larger flows such that an accurate representation is obtained from a 


subset of total flow while maintaining statistical variance. This is possible 
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because a large fraction of network traffic is contained within a small subset of 
flows. Smart sampling utilizes one of two methods. Threshold sampling [8], [9] 
is based on the characteristics of the packet stream and priority sampling [10], 
[11] which seeks a fixed number of the highest ranked samples found in a 


population. 


A NetFlow data record is a simple text file where each line represents a 
single flow and each metric is comma delineated. It contains many metrics to 
which the full extent go beyond the scope of this research. Rather, only the 
pieces of information that fit the PacketSet 5-tuple data structure were extracted. 


The parsed NetFlow data record was maintained using the following line format: 





{Source IP, Source Port Number, 
Destination IP, Destination Port Number, 
Protocol, 

Ingress Router:Inbound Interface, 

Egress Router:Outbound Interface} 




















The reason NetFlow data was selected to conduct the validation testing is 
because it represents packet flows that have successfully passed the security 
policies implemented on the network. It fits nicely into the previously described 


framework where the set of packets permitted from ingress router i to egress 


router j is based on the ACLs encountered on each interface (u,v) respectively 


(Figure 1). 


Ingress Router, / eee Egress Router, / 
via Interface, u . = via Interface, v 


Tier-1 ISP Network 





Figure 1. NetFlow Ingress and Egress 
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lll. VALIDATION METHODOLOGY 


The validation methodology is a rather straightforward comparison 
between the reachability upper bound and the NetFlow data. Cases where a 
flow is found to fail validation requires some discussion as there could be various 
reasons and contributing factors. Also of importance are the specific validation 
results that this research most conclusively aims to discover. The design of the 


automated validation process is outlined as well. 


A. REACHABILITY VALIDATION CORRECTNESS 

The terms of reachability validation require some qualification as to the 
definition of correctness. There are four error cases that must be considered 
when interpreting the meaning of validity, but there two probable reasons (Table 
1). The first reason can be due to a bug or discrepancy found within the RUB 
computation implementation. The second error type accounts for limitations that 
might be introduced as a result of not modeling routing protocols into the RUB 


computation, but does not leave out the possibility of a bug in the software either. 


Error Type | Error Description Possible Reason 
Flow mistakenly excluded from 
reachability upper-bound Software bug since routing 


Flow mistakenly included in only decreases reachability 
poses Supe reachability lower-bound 


False Deny 1 


Flow mistakenly excluded from ree: 
False Deny 2 reachability lower-bound Limitation due to not 


modeling routing protocols 
Flow mistakenly included in 
False Permit 2 reachability upper-bound or due to software bug 





Table 1. Validation Error Cases 


An early assumption is made which maintains the fidelity of NetFlow data 
such that the flows it represents encountered packet filter rules that were 
implemented correctly. Alternatively stated, all of the NetFlow data is expected 


to be found within the RUB provided the computation is correct. This is a fair 
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assumption which places trust in the tier-1 ISP network design while ensuring 
that the scope of the research remains on validation of the RUB computation. 
Based on that premise, only the False Deny 1 and False Permit 2 error cases 
apply. Though the latter case can feasibly occur, it cannot be conclusively 
determined within the scope of this research because the effects of routing 
protocols are not considered into the reachability computation. Therefore, the 
only conclusive result that can be determined from this research is in the False 
Deny 1 error case since the only possible reason stems from a bug in the RUB 


software. 


A mathematical representation of the False Deny 1 and False Permit 2 
error cases is in Table 2 where N represents the set of all potential packets 


permitted to traverse the network and f is the NetFlow data. 


Error Type Mathematical Description Result 
False Deny 1 f <¢N,f ¢ RUB Bug in code 





False Permit 2 f¢éN,f ¢ RUB Inconclusive 


Table 2. | Mathematical Description of RUB Validation Error Types 


B. AUTOMATED VALIDATION DESIGN 

Since the RUB computation is represented by a range of accepted values, 
a simple check against each data field of the RUB computation is conducted to 
determine if the corresponding field of the NetFlow data is within those bounds. 
A flow is considered valid if all of its information falls within the bounds of the 
RUB. Otherwise it is considered to have failed validation. 


1. Main Algorithm 
A new Main function was developed in order to organize output, direct 
access to data sets for processing (e.g. NetFlow data and router configuration 


files) and begin the validation test. To increase efficiency, information such as 
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the parsed NetFlow data and the processed network configuration are saved to a 
file. Future runtime using the saved network configuration file is reduced from 


near 5 hours to only 20 minutes. 


The parsed NetFlow data is output to a file which is then read into the 
program by the NetflowValidator function. (The details of which will be 
introduced in the following section.) A benefit of this allows for custom files to be 
created for the purposes of conducting tests on specific security policies, 
simulate network traffic (“what-if” tests) or to inject known packet flows that were 


not sampled by NetFlow. A brief algorithm explains the top level Main function: 


po 
. 





Initialize data and results directories; 





Check for parsed NetFlow file; 


if it exists continue; 





else parse raw NetFlow data and save file; 





Check for saved router configuration; 





if it exists load file; 





else parse router configuration files; 


Conduct neighbor discovery; 


Oo GO HAND oO SF W ND 


PacketSet creation; 


10:5 Save file; 














11. Invoke NetflowValidator 





2: NetflowValidator Algorithm 

The validation process is handled by a _ new function § called 
NetflowValidator. It is invoked after the raw NetFlow files are parsed and all 
network configuration PacketSets have been created. As each line of NetFlow is 
read, a RUB computation is conducted based on the ingress and egress routers 
identified per flow but only if it has not already been completed. This check is in 
place to increase efficiency since it is possible that the same pair of routers can 


be used for various flows. There is no need to compute the RUB again. 


In some cases the actual egress router used by the flow was discernable 
by the NetFlow technology which resulted in multiple egress routers for a single 
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ingress router reported in the data record. This is handled by computing the 
RUB and validation test for each pair of routers. 


Also included is a simple check to determine if a path exists (connectivity) 
between the ingress and egress routers based on the computed PacketSets. An 
open source Java based networking utility simulating Dijkstra’s algorithm was 
used for this operation [12]. Initially implemented as an efficiency mechanism, it 
also serves to highlight possible errors in router configuration processing or raise 


connectivity concerns. (Appendix A) 


The following algorithm of the NetflowValidator function provides more 


detail: 


For each line of NetFlow data do; 
Check for multiple egress routers; 
if single egress router do 
RUB check; 
if previously computed, load, continue; 
else check for path, compute RUB and save; 


if multiple egress routers do; 





RUB check for each egress router; 


OO OW AND oO FPF W NY FE 


if previously computed, load, continue; 
10. else check for path, compute RUB and save; 


11. Conduct validation test; 








12. for each data field; 





{Source IP Address Range; 


Source Port Number Range; 








Destination IP Address Range; 











Destination Port Number Range; 


Protocol Number Range} 





133 if NetFlow data field exceeds bounds of 








PacketSet data field return false; 


14. else return true; 





15. Output and save results; 
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IV. IMPLEMENTATION 


The development and actual implementation of the validation research is 
explored in this chapter. Changes to reachability software, development of new 
code, utilization of existing code as well as limitations and bottlenecks discovered 
are outlined. Then the validation results are introduced and analyzed. Lastly, a 


discussion is had on recommended future work and conclusions. 


A. SOFTWARE IMPLEMENTATION 

Since the data sets for this research were provided by a Tier-1 ISP, the 
proprietary information was required to remain on their systems. All of the 
software involved in this research was executed on the ISP research systems via 
a secure remote connection. The system was a sparc SUNW, Sun-Fire-15000 
processor platform running SunOS 5.8 that had approximately 204 Gigabytes of 
memory and 54 Central Processing Units. The software was implemented using 
Eclipse SDK version 3.2.2 and compiled using Java version 1.5.0 _06-b05. Perl 
version 5.005 _03 was used in executing the NetFlow parser script which was 
provided by the ISP technicians. 


1. Modifications to the Static Reachability Analysis Toolkit 
Changes to the original software [4] were necessary in order to create an 
automated validation process using the NetFlow data within the confines of the 
collaborating ISP remote system. Further alterations were required to improve 
efficiency as a result of the complexity introduced by such a large data set. Few 
modifications were made to the parsing process in order to facilitate the process. 
No changes were made to the implemented logic for computing the reachability 
upper bound. 
a. GUI Replacement 
The Toolkit code utilized a Graphical User Interface (GUI) for the 
input of the router configuration data set and the selection of source and 
destination routers for the reachability analysis. This was deemed impractical for 
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the purposes of this research considering that an automated solution was desired 
for such a large data set. In place of the GUI, the Main function described in 
Chapter Ill was created (code is provided in Appendix B) to handle program 
startup, organization of input and output files, and invoke the parsing and 
automated validation processes. 

b. Modifications in Parsing 

During trials with the ISP router configuration files, parsing errors 
were encountered with the proper translation of protocol and port names to their 
corresponding numerical value designated by the Internet Assigned Numbers 
Authority. The reason was found to be related to variances used by Cisco in the 
shorthand notations of the protocol and port names. Another factor was that the 


list of number conversions included in the code was quite limited. 


The solution was to create two functions which served as a port 
and protocol name to number conversion database. It is intended to be a near 
exhaustive list extracted from those found within system files (see Appendix C for 
the PortDatabase function). Due to further variances however, a custom file had 
to be constructed for the protocol numbers. As such, it is required to be located 
in the same directory from which the validation program is executed (see 
Appendix D for the ProtocolDatabase function). 

Cc. Time and Process Efficiency Implementation 

Two features of Java were implemented to take advantage of the 
computation power and large memory of the computer system used for this 
research. The total time for PacketSet creation was significantly reduced by 
using a 300 thread pool. Additionally, serialization was implemented to 
streamline the processing of the network configuration files into PacketSet and 
Router Configuration objects. Router configuration file parsing as well as 
neighbor discovery also experienced faster total process times each with a 100 


thread pool. 
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2. Automated Router Selection and Validation 

Router selection automation is achieved by modifying the original 
PathChooser function to accept the ingress and egress routers listed per line of 
NetFlow data instead of those manually specified by a user via the GUI. The 
new function, named PathChooserEvolved (Appendix E), is invoked by a new 
function called SRADatabase (Appendix F) which tracks if a RUB computation 
between the two routers already exists. If it does not exist, then SRADatabase 
passes the ingress and egress routers obtained via the NetflowValidator function 
(Appendix G) to PathChooserEvolved for reachability computation. The following 


algorithm outlines this process: 


1. Main function invokes NetflowValidator; 


2. For each line of NetFlow data the 
NetflowValidator obtains the ingress and 
egress router names; 











3. Router names are passed to SRADatabase to 
check if RUB computation exists; 


4. 1£ RUB computation exists; 





are Load information and return to 
NetflowValidator for test; 





6. else pass router names to PathChooserEvolved; 




















Ts PathChooserEvolved invokes RUB computation 
and returns information to SRADatabase for 
storage; 

8. Information retrieved by NetflowValidator 
for test; 





9. Continue; 


B. VALIDATION RESULTS AND ANALYSIS 

The results of the automated validation program are rather 
straightforward. As previously mentioned, each line of NetFlow data represents 
a single flow that was tested against the static reachability upper bound 
calculation. A line is considered to have passed validation if all of its data field 
values fit within the range determined by the RUB. Those lines that were 
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determined to fail validation are analyzed for likely reasons. Limitations and 


bottlenecks that affected the validation process are also addressed therein. 


1. Validation Results 

Validation processed 100,826 lines of NetFlow data and computed 1,281 
static reachability upper bound computations over a network of near 800 routers 
in about 10 days, 5 hours and 43 minutes. Final results revealed that 
approximately 66 percent of the NetFlow data passed validation where 34 
percent failed. Tables 3 and 4 provide further details. Note that validation time is 
dominated by the time to compute each RUB (the time required for the actual 
validation check is negligible) and is separate from the time it takes to process 


the configuration files into the framework (PacketSets). 


Result Number of Lines Percentage of Total Lines 


Passed Validation | 66,663 66% 





[66% 
Failed Validation | 34,163 


Table 3. Validation Results 


Process Run Time 


Network Configuration | 4 hours, 50 min 


Validation 10 days, 5 hours, 43 min 
RUB Computation 


Table 4. | Processing Times 





a. Memory and Space Complexity 

The software is quite memory intensive. Initial trials of this 
research encountered OutOfMemory errors caused by reaching the default heap 
space that Java 1.5 allows. The network configuration must be maintained within 
memory as well as each RUB computation. Considering the magnitude of 


information that must be handled for a Tier-1 ISP, compounded at times by the 
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use of at most 300 concurrent processes, the likelihood of such an error was 


highly probable though originally unanticipated. 


The system testbed was more than capable of providing an 
adequate amount of memory with over 200GB available. Through 
troubleshooting, 3GB was determined to be the most allowed by Java. 


Implementing the —Xmx3g option alleviated the problem. 


b. Time Complexity 

PacketSet creation is processing intensive since the time 
to process one ACL is proportional to the square of the total number of rules 
comprised within it. There were approximately 688 discrete ACLs processed for 
a combined total of 32,160 rules on this Tier-1 network of near 800 routers. 
Though the time elapsed is attributed to the processing of 70,297 individual ACLs 


for a combined total of approximately 3,313,607 rules. 


The process of parsing the configuration text files and creating 
PacketSets into a representative network configuration averaged about 5 hours. 
If changes to the router configuration files are uncommon, this can be considered 
a one time cost of processing overhead because it is saved to an output file as 
implemented in the Main function. Subsequent runs required only 20 minutes to 


load the router configuration file. 


A major bottleneck of the validation process is the RUB 
computation as each averaged about 11 minutes each. For a network size such 
as the Tier-1, it would take about two weeks to determine the reachability 
between all router pairs implementing efficiency methods such as a 300 thread 
pool. This was considered to be a worst case scenario however in that the 
NetFlow data only represents a subset of total flow. Hence, only the necessary 
reachability tests were conducted per NetFlow data. 


2. Results Analysis 
The two-thirds majority of valid NetFlow data is rather encouraging 


because it demonstrates that the static reachability analysis framework and 
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implementation functions as hoped. It is the remaining third of data that requires 
closer inspection as to the cause for validation failure. Based on previous 
discussion regarding error cases, the reason was expected to be found within the 


software. 


A quick inspection of the failed NetFlow lines revealed no discrepancy that 
indicated a parsing error. Thus the focus of attention turned to an exploration of 
the ACLs that those packet flows would encounter on the network. This required 
a review of the RUB computation and the original router configuration files. 


It was discovered that in each failed case randomly selected for inspection 
that no RUB was found between the router pair. For there to be no RUB 
computation would imply that none of the ACLs on both the ingress or egress 
router intersected, thus concluding no reachability rendering the line of NetFlow 
data to be erroneous. Surely this was not true based on the known 
characteristics of the NetFlow data. 


The next logical step was to confirm the presence of ACLs applied to the 
router pair or possibly the lack thereof. However, the latter case where no filters 
are applied to a router interface is handled within the SRA software by assigning 
apermit any filter. If that were to have occurred, then the NetFlow line would 


have passed validation. 


Both the PacketSet data and the router configuration file confirmed the 
presence of ACLs applied to each router pair. Close study of the syntax used in 
the router configuration files disclosed a critical discrepancy with the software. 
The version of Cisco IOS used by the Tier-1 ISP included the feature of IP 
named ACLs in addition to the traditional use of numbered designation [13]. The 
SRA software focuses only on the latter, which indicated that those IP named 
ACLs were not being properly accounted for in the RUB computation. 


Since there were ACLs applied to the interfaces of ingress and egress 


routers, an implied deny all resulted for the remaining set of packets that 
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were not listed. Hence, because of this it can be said that those lines of failed 
NetFlow data depended on the missing packet filters in order to be recognized as 
valid. 


23 


THIS PAGE INTENTIONALLY LEFT BLANK 


24 


V. RECOMMENDATIONS AND CONCLUSION 


The final chapter of this thesis identifies areas for improvement of the 
current reachability software to include future work regarding the next stage of 
implementing the SRA framework. Final comments mark the conclusion of this 


research. 


A. RECOMMENDATIONS FOR FUTURE WORK 

Initial Suspicion directed by the False Deny 1 error case proved to be 
correct. The existence of a bug in the software was indeed found. The SRA 
Toolkit only handles numbered ACLs. The fact that a third of the NetFlow data 
failed in relation to this illustrates the likelihood of encountering the usage of IP 
named ACLs in the future. Thus, it should be incorporated into the program. As 
it currently stands, implementation is designed to only handle integers. 
Modifications are required which will enable these ACLs to be properly parsed 
and processed into PacketSet data structures that handle strings as well. 


The router configuration file parser could be made more efficient. Those 
interfaces that have a private or loopback IP address should be recognized and 
ignored. A considerable amount of interfaces were actually named Loopback. 
The ability to identify these for exclusion is recommended as well. If insignificant 
items such as these are not considered for processing, time and memory 


complexity would be reduced to a degree. 


Performance could potentially be improved by implementing a mechanism 
which saves the RUB computations in a similar design as was the router 
configuration in this research. This would enable future validation tests to be 
conducted more quickly assuming no changes were made to the network. Once 
routing protocol or policy is implemented into the program, it may be possible to 
only update the RUB database even if changes are made. 
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B. CONCLUSION 

This research served an important role in the development of an 
automated solution for static analysis of network reachability as it performed the 
first rigorous test of the only known SRA tool implementation [4]. With the 
majority of NetFlow lines found valid, static reachability analysis has been 
demonstrated to be a viable solution suitable for security policy validation. The 
creation of an automated validation mechanism provides the basis for testing 


future work as a complete solution is sought. 


Completion of this stage of development is highly anticipated. The next 
step in this research should be to implement the reachability lower bound with 
regards to packet filters. Once this is accomplished, along with previously 
mentioned modifications, yet another automated validation test will be required. 
Pending those results, the packet filter aspect of network reachability will have 


been properly addressed. 


The benefits of incorporating the affect of routing policies on network 
reachability are apparent even in this research. It is the next logical aspect of 
static reachability analysis that can be modeled into the proposed framework. A 
rather powerful tool will result when combined with the packet filter component. 
Though Java was the preferred tool of implementation in this research, more 
efficient and computationally powerful alternatives may prove to be beneficial in 


experimental evaluation regarding this aspect. 


Research in static reachability analysis has proven successful thus far. 
Significant progress has been made through the development of a framework, 
creation of a working implementation regarding the packet filter aspect, and now 
the rigorous validation of such. The successful incorporation of routing policy 
and packet transformations to static analysis will result in a first of its kind 
solution to designing networks more efficiently while ensuring correct 


implementation though semantic verification. 
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APPENDIX A. NETWORKGRAPH2.JAVA 


package StaticReachabilityAnalysis; 





























import StaticReachabilityAnalysis.*; 
import java.awt.Font; 

import java.io.BufferedInputStream; 
import java.io.File; 

import java.io.FileInputStream; 

import java.io.FileNotFoundException; 
import java.io.FileOutputStream; 
import java.io.IOException; 

import java.io.ObjectInputStream; 
import java.util.HashMap; 

import java.util.Iterator; 

import java.util.Random; 

import java.util.zip.GZIPInputStream; 
import java.util.zip.GZIPOutputStream; 
import mascoptLib.abstractGraph.AbstractPath; 
import mascoptLib.algos.abstractalgos.Dijkstra; 
import mascoptLib.gui.*; 

import mascoptLib.graphs.*; 

import mascoptLib.io.graph.MGLReader; 
import mascoptLib.io.graph.MGLWriter; 
public class NetworkGraph2 { 





private HashMap nameToVertexMap = new HashMap (); 
private DiGraph graph = null; 





public NetworkGraph2 (NetworkConfig conf) { 


HashMap ipToPairMap = initMap (conf); 
VertexSet ns = new VertexSet(); 
ArcSet asl = new ArcSet (ns); 





Iterator routers = conf.tableOfRouters.values().iterator(); 


while (routers.hasNext()) { 
RouterConfig currentRouter = 
(RouterConfig) routers.next (); 
Vertex v = new Vertex(); 








nameToVertexMap.put (currentRouter.hostName.toLowerCase(), 
ns.add(v); 


} 
routers = conf.tableOfRouters.values().iterator(); 


while (routers.hasNext()) { 
RouterConfig currentRouter = 
(RouterConfig) routers.next(); 
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Iterator interfaces = 


currentRouter.tabl 





OfInterfaceByNames.values().iterator(); 


while (interfaces.hasNext()) { 
InterfaceConfig iconf = 


(InterfaceConfig) interfaces.next (); 


for(int i=0; i<iconf.neighbors.size(); i++) { 
String ip = 


(String) iconf.neighbors.get (i); 


InterfacePair ipair = 


(InterfacePair) ipToPairMap.get (ip); 


Vertex vl = 


(Vertex) nam 





ToVertexMap.get (currentRouter.hostName) ; 


Vertex v2 = 





(Vertex) nam 





ToVertexMap.get (ipair.rconfig.hostName) ; 





asl.add(new Arc(vl, v2)); 


} 


//create logical graph 
graph = new DiGraph(ns,as1l); 
graph.setName (conf.networkName) ; 


private HashMap initMap(NetworkConfig nconfig) { 


HashMap ipToPairMap = new HashMap (); 


Iterator routers = 


nconfig.tableOfRouters.values().iterator(); 


while (routers.hasNext()) { 


RouterConfig 


currentRouter = 


(RouterConfig) routers.next(); 


Iterator ips 


currentRouter.tableOfInterfaceByIPs.keySet().iterator(); 
while (ips.hasNext()) { 
String ip = (String)ips.next(); 


InterfaceConfig iconfig = 
(InterfaceConfig) currentRouter.tableOfInterfaceByIPs.get (ip); 





if (ipToPairMap.containsKey(ip)) { 


System.out.printin ( 








"ERROR: NOT UNIQUE IPs (" 


+ currentRouter.hostName + ", " 
+ iconfig.interfaceName + ", " 
+ ip + sa RL 

continue; 


} 





InterfacePair pair = new 
InterfacePair(currentRouter, iconfig); 
ipToPairMap.put (ip, pair); 


return ipToPairMap; 
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(Vert 





public boolean doesPathExist (String src, String dst) { 


Dijkstra dj = new Dijkstra(graph) ; 


Vertex source = 





(Vert 


x)nameToVertexMap.get (src.toLowerCase()); 
Vertex destination = 











("Sourc 


x)nameToVertexMap.get (dst.toLowerCase()); 


if (source == null) { 
System.out.printin 








return false; 


if (destination == null) { 
System.out.printin 


router "+ src + " not found in NetworkGraph."); 


("Destination router " + dst + " not found in NetworkGraph."); 


return false; 


} 


if (source.getDegree (graph) == 0 || 


destination.getDegree(graph) == 0) { 


return false; 


} 
dj.valuateFromSource (source) ; 


AbstractPath p = null; 
try{ 


p = dj.getShortestPathTo (destination) ; 





} catch(Exception e) { 
System.out.printin 





("CANT CALC PATH: " 4 .getMessage()); 


} 
return (p != null); 
private static class InterfacePair { 


public InterfaceConfig iconfig; 
public RouterConfig rconfig; 





public InterfacePair(RouterConfig router, 
{ 
iconfig = iface; 
reonfig = router; 
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InterfaceConfig 
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APPENDIX B. MAIN.JAVA 


package StaticReachabilityAnalysis; 

















import java.io.BufferedInputStream; 
import java.io.BufferedOutputStream; 
import java.io.File; 

import java.io.FileInputStream; 
import java.io.FileNotFoundException; 
import java.io.FileOutputStream; 
import java.io.IOException; 

import java.io.InputStream; 

import java.io.ObjectInputStream; 
import java.io.ObjectOutputStream; 
import java.util.Iterator; 

import java.util.zip.GZIPInputStream; 
import java.util.zip.GZIPOutputStream; 








[KOR KR KR KKK KK KK RK IR I I I RK AK OK KK 


* New main for non-GUI interface 
KOK HR I I I I I I I I I I OK I OK / 
public class Main { 


private static final String CONFIGS_INPUT_BASE 
"/ipso/netdb_1/cbb/"; 




















private static final String NETFLOW_COMMAND = 
"perl /ipso/project_6/reachability/netflow.pl"; 


private static 


s String 
private static 

Ss 

Ss 


String 
String 
String 
String 


parentDir; 
SRAOutputDir; 
parsedConfigsDir; 
netflowOutputFile; 
configsInputDir; 


private 
private 
private 











private static String savedNetworkConfig; 


private static boolean DEBUG = false; 








private static void 
String day) { 
parentDir = "/ipso/project_6/reachability/" + y 
month + "_" + day + "-results/"; 
SRAOutputDir = parentDir + "SRAOutput"; 


parsedConfigsDir = parentDir + "parsedConfigs"; 


initDirectories (String year, String month, 











File SRA = new File(SRAOutputDir); 











File parsedConfigs = new Fil 


// create static reac 
if (SRA.exists() == fa 
boolean result 


(parsedConfigsDir) ; 





hability analysis directory 
lse) { 


= SRA.mkdirs(); 
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if(result == false) { 
System.err.printin("SRA dir creation failed!"); 
System.exit (-1); 
} 





} 


//create parsedconfigs directory 








if (parsedConfigs.exists() == false) { 
boolean result = parsedConfigs.mkdirs(); 
if(result == false) { 
System.err.printin 
("parsedConfigs dir creation failed!"); 


System.exit(-1); 






































netflowOutputFile = parentDir + "netflowOutput.txt"; 
configsInputDir = CONFIGS_INPUT_BASE_ DIR + year + month + 
day + Ws 

savedNetworkConfig = parentDir + "networkConfig.sav.gz"; 
System.out.printin("SRA output dir: " + SRAOutputDir); 
System.out.printin 
("parsedConfigs output dir: " + parsedConfigsDir); 
System.out.printin 
("netflow.pl output file: " + netflowOutputFile); 
System.out.printin 
("configs input dir: " + configsInputDir); 
System.out.printin 
("NetworkConfig savefile: " savedNetworkConfig) ; 

} 

private static void saveNetworkConfig(NetworkConfig config) { 


Ey if 
FileOutputStream fos = new 
FileOutputStream(savedNetworkConfig) ; 
BufferedOutputStream bos = new 
BufferedOutputStream(fos) ; 
GZIPOutputStream gzos = new GZIPOutputStream(bos) ; 
ObjectOutputStream oos = new 
ObjectOutputStream(gzos) ; 
oos.writeObject (config) ; 
oos.flush(); 
oos.close(); 

} catch (FileNotFoundException e) { 
e.printStackTrace(); 

} catch (IOException e) { 
e.printStackTrace(); 

















private static NetworkConfig loadSavedNetworkConfig( ) { 
NetworkConfig result = null; 
try { 
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FileInputStream fis = new 
FileInputStream(savedNetworkConfig) ; 
BufferedInputStream bis = new 
BufferedInputStream(fis); 
GZIPInputStream gzis = new GZIPInputStream(bis) ; 
ObjectInputStream ois = new ObjectInputStream(gzis) ; 
result = (NetworkConfig) ois.readObject (); 
ois.close(); 
return result; 

} catch (FileNotFoundException e) { 
e.printStackTrace(); 

} catch (IOException e) { 
e.printStackTrace(); 

} catch (ClassNotFoundException e) { 
e.printStackTrace(); 




















return null; 





private static void printTime(long millis) { 


long ms = millis % 1000; 
millis /= 1000; 








long seconds = millis % 60; 
millis /= 60; 











long minutes = millis % 60; 
millis /= 60; 























long hours = millis % 24; 
System.out.print (hours + "h " + minutes + "m " + seconds + "s " 
+ ms + "ms"); 


} 





// java Main 2007 01 11 

// arg[0] = year 

// arg[1] = month 

// arg[2] = day 

public static void main(String args[]) { 
String year = args[0]; 


String month = args[1]; 
String day = args[2]; 


if(args.length < 3 || args.length > 4) { 
System.out.printin("Syntax Error! Enter Month Day Year"); 
System.exit(-1); 








} 
if(args.length == 4) { 
DEBUG = true; 





} 
initDirectories(year, month, day); 


long wholeBefore = System.currentTimeMillis(); 
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try { 





String cmd = NETFLOW_COMMAND 
year 

month 

day 

as netflowOutputFile; 























File netflowFile = new File (netflowOutputFile) ; 
if (netflowFile.exists() == false) { 
System.out.printlin("Running command: '" + cmd + "'"); 


Process child = Runtime.getRuntime().exec (cmd) ; 

InputStream in = child.getInputStream() ; 

int c; 

whil ((c = in.read()) != -1) f 
System.out.print ((char)c); 
System.out.flush(); 

} 








} else { 

System.out.printin 

(netflowOutputFile + " already exists!"); 

} 

File configsInput = new File(configsInputDir) ; 





File parsedConfigsOutput = 
new File (parsedConfigsDir) ; 





NetworkConfig network = null; 


























File savedFile = new File(savedNetworkConfig) ; 
if (savedFile.exists()) { 
long before = System.currentTimeMillis(); 
System.out.printin 
(savedNetworkConfig + " exists - loading data!!"); 
network = loadSavedNetworkConfig(); 
long after = System.currentTimeMillis(); 
System.out.printin 
("Loading file took " (after—-before) "ms"); 
} else { 
System.out.printin 
(savedNetworkConfig + " doesnt exist parsing 
config files!"); 
network = new NetworkConfig(); 


new Parser (network, configsInput, 
parsedConfigsOutput) ; 

saveNetworkConfig (network) ; 
System.out.printin("NetworkConfig saved"); 
//Enable data dump for debugging 

new NetworkDataDump (network, 
parsedConfigsOutput) ; 





Iterator 1 = 
network.tableOfRouters.keySet().iterator(); 
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NetflowValidator nfv = new 
Net flowValidator (netflowOutputFile, SRAOutputDir, network); 


= System.currentTimeMillis(); 





long validBefor 
nfv.startValidation(); 
long validAfter = System.currentTimeMillis(); 











System.out.print ("Validation took "); 
printTime (validAfter-validBefore) ; 
System.out.printin(); 


} catch (IOException e) { 
e.printStackTrace (System.err) ; 





} 
long wholeAfter = System.currentTimeMillis(); 





System.out.print ("Whole process took "); 
printTime (wholeAfter-—wholeBefore) ; 
System.out.printin(); 
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APPENDIX C. 


package StaticReachabilityAnalysis; 


impor 
impor 
impor 
impor 
impor 
impor 
impor 





rtttt tc ct 





ava.io.IOException,; 


ava.util.HashMap; 





[ea yan FO i 








public class PortDatabase { 


private static HashMap database 


private static final String S 


ava.io.BufferedReader; 
ava.io.FileInputStream; 


ava.io.InputStreamReader; 
ava.sql.DatabaseMetaData; 


ava.util.StringTokenizer; 


PORTDATABASE.JAVA 


= null; 








ERVICES_FILENAME 




















= "/etc/services"; // aka /etc/inet/services 
// c:\winnt\system32\drivers\etc\services on Win NT/2000 





public static String getPortByName(String name) { 

if (database == null) { 
new HashMap (); 
generateDatabase(); 


database = 


} 


return (String) database.get (name) ; 


private static void parseServicesLine (String line) { 
SS || line.charAt(0) == '#') { 


if (line.length () 
return; 


} 


// Parse line 
StringTokenizer 





st = new 





StringTokenizer(line, " \t/#"); 


// First get the name on the line (parameter 1): 


if (! st.hasMoreTokens () ) 
return; // error 





{ 


String name = st.nextToken().trim(); 











Next get th 
( 


} 
String portValu 


! st.hasMoreTokens () ) 
return; // error 


service name on the line (parameter 2): 


= st.nexti 





Token().trim(); 


// Finally get the class on the line (parameter 3): 


if (! st.hasMoreTokens () ) 








return; // error 


} 


String classValu 





= st.nextToken().trim(); 
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// else if (port.equalsIgnoreCase(".,..")) portNumber= ".."; 


if (database.containsKey(name)) { 
return; 


} 


database.put (name, portValue); 





} // parseServicesLine() 

private static void generateDatabase( ) { 
int port = -1; 
try { 


String line; 
BufferedReader br = new BufferedReader ( 
new InputStreamReader ( 
new FileInputStream ( 
SERVICES_FILENAME) ) ) ; 























// Read /etc/services file. 
// Skip comments and empty lines. 














while ((line = br.readLine()) != null) { 
parseServicesLine (line) ; 
} // while 


br.close(); 





} catch (IOException ioe) { 
// File doesn't exist or is otherwise not available. 
// Keep defaults 
loe.printStackTrace(); 
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APPENDIX D. 


PROTOCOLDATABASE.JAVA 


package StaticReachabilityAnalysis; 


impor 
impor 
impor 
impor 
impor 
impor 
impor 





rtttt tc ct 





public 


ava.io.IOException,; 





ava.util.HashMap; 





[ea yan FO i 





ava.io.BufferedReader; 
ava.io.FileInputStream; 


ava.io.InputStreamReader; 
ava.sql.DatabaseMetaData; 


ava.util.StringTokenizer; 


class ProtocolDatabase { 





private static HashMap database 


private static final String S 


= null; 








ERVICES_FILENAME 

















= "protocols"; // aka /etc/inet/services 
// c:\winnt\system32\drivers\etc\services on Win NT/2000 





public static String getProtocolByName (String name) { 

if (database == null) { 
new HashMap (); 
generateDatabase(); 


database = 


} 


return (String) database.get (name) ; 


private static void parseServicesLine (String line) { 
SS || line.charAt(0) == '#') { 


if (line.length () 
return; 


} 


// Parse line 
StringTokenizer 





st = new 





StringTokenizer(line, " \t/#"); 


// First get the name on the line (parameter 1): 


if (! st.hasMoreTokens () ) 
return; // error 





{ 


String name = st.nextToken().trim(); 











Next get th 
( 


} 
String portValu 


! st.hasMoreTokens () ) 
return; // error 


service name on the line (parameter 2): 


= st.nexti 





Token().trim(); 


// Finally get the class on the line (parameter 3): 


if (! st.hasMoreTokens () ) 








return; // error 


} 


String classValu 





= st.nextToken().trim(); 
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if (database.containsKey(name)) { 
return; 


} 


database.put (name, portValue); 





} // parseServicesLine() 

private synchronized static void generateDatabase( ) { 
int port = -1; 
Ey of 


String line; 
BufferedReader br = new BufferedReader ( 
new InputStreamReader ( 
new FileInputStream ( 
SERVICES_FILENAMB) ) ); 


























// Read /etc/services file. 
// Skip comments and empty lines. 











while ((line = br.readLine()) != null) { 
parseServicesLine (line) ; 
} // while 


br.close(); 





} catch (IOException ioe) { 
// File doesn't exist or is otherwise not available. 
// Keep defaults 
loe.printStackTrace(); 


} 


public static void main(String args[]) { 
System.out.printin(getProtocolByName ("pim") ); 





} 
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APPENDIX E. PATHCHOOSEREVOLVED.JAVA 


package StaticReachabilityAnalysis; 
import java.util.*; 

import java.io.*; 

import javax.swing.*; 





public class PathChooserEvolved { 
NetworkConfig theNetwork = null; 
String theOutputDir = null; 


private int getRouterIndex(String routerName) { 
System.out.printin("Trying to find router: " + routerName) ; 





Iterator routerList = 
theNetwork.tableOfRouters.keySet ().iterator(); 





int i=0; 
while (routerList.hasNext()) { 
String router = (String) routerList.next (); 
if (router.equalsIgnoreCase(routerName)) { 
return i; 
} 
Ty 


} 


return -1; 


/** Creates new form PathChooser */ 
public PathChooserEvolved(NetworkConfig network, String outputDir) 





theNetwork = network; 
theOutputDir = outputDir; 


[KOR RR KKK KK KR KK IR I IR I RK OK OK 
KKKKKKKKK 
* 


* Run the reachability computation code 
* 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
KKK KK KK / 


public PacketSet ComputeNow(String ingress, String egress) { 


boolean successComputeNow=false; 
boolean successFileSave=false; 











String sourceName = ingress; 
String destinationName = egress; 


PacketSet rUB = new PacketSet(); 


PacketSet rLB = new PacketSet(); 
[RRR RR KKK KKK KKK KK KK KK KK 
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* Display reachability calculation information on default 


system.out display 
KKK KK KK KK KK OK KK / 


System.out.printin ("=== Calculating Reachability ==="); 














// workaround for current code. 
int source = getRouterIndex (sourceName) ; 
int destination = getRouterIndex (destinationName) ; 








if(source == -1 || destination == -1) { 
System.out.println("DEBUG - Either source or destination 
routers not in router index!"); 
return null; 











rUB = rUB.InitializePath(theNetwork, source, destination, rLB); 


[RR KK RK KKK KK KK KKK KK OK 
* Save reachability calculation results to a file in the 


output directory 
KOK KOK RK KK OK KK KK / 


String outputFileName = "SRA_" + sourceName + "_to_" + 
destinationName + ".txt"; 








System.out.printin("Writing results to " + outputFileName) ; 





try { 
File outputFile = new File (theOutputDir, outputFileName) ; 
PrintWriter outFile = new PrintWriter (outputFile); 


outFile.printin("Reachability Upper Bound from " + 
sourceName + " to " 





+ destinationName + " : "+ "\r\n"); 
outFile.printin(ruUB) ; 
outFile.close(); 
successFileSave = true; 

} catch (Exception e) { System.out.printin ("Error —- £eeyy, } 


























successComputeNow = true; 
return ruUB; 
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APPENDIX F. SRADATABASE.JAVA 


package StaticReachabilityAnalysis; 


import java.util.HashMap; 
import java.util.LinkedList; 





public class SRADatabase { 


// a map from a ingress/egress router pair to a packetset 
// that is generated from SRA analysis 
private static HashMap<String, PacketSet> database = 

new HashMap<String, PacketSet>(); 


// NetworkConfig is generated from Parser 

private NetworkConfig networkConfig; 

// Where to put SRA files, even though we dont technically need 
them 

private String SRAOutputDir; 





private LinkedList<String> noPathExistsList = new 
LinkedList<String>()j; 





private NetworkGraph2 networkGraph = null; 


public SRADatabase(NetworkConfig config, String SRAOutputDir) { 
networkConfig = config; 
this.SRAOutputDir = SRAOutputDir; 
networkGraph = new NetworkGraph2 (config) ; 





} 


// Returns a packetset if we have already generated it, otherwise 
// it is generated and placed in the map. 
public PacketSet getPacketSet (String ingressRouter, String 
egressRouter) 
throws PathNotPossibleException { 
String key = ingressRouter + "-" + egressRouter; 

















if (database.containsKey(key)) { 
return database.get (key); 





if (noPathExistsList.contains(key)) { 
throw new PathNotPossibleException(ingressRouter, 








egressRouter) ; 


} 





if (networkGraph.doesPathExist (ingressRouter, egressRouter) 
== false) { 
noPathExistsList.add (key) ; 








throw new PathNotPossibleException(ingressRouter, 





egressRouter) ; 


} 
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PathChooserEvolved pce = new 
PathChooserEvolved(networkConfig, SRAOutputDir) ; 
PacketSet ps = pce.ComputeNow(ingressRouter, egressRouter) ; 








if(ps == null) { 
return null; 


database.put (key, ps); 


return ps; 


44 


APPENDIX G. NETFLOWVALIDATOR.JAVA 


package StaticReachabilityAnalysis; 
//package StaticReachabilityAnalysis; 
import java.io.*; 

import java.text.*; 


import java.util.ArrayList; 


[KR KR KKK KK KK RK KR I RK OK KK 


* Reader function for parsed NetFlow data 
HOKE I  I  I R  / 
public class NetflowValidator { 

private File netflowFile = null; 

private SRADatabase sraDatabase = null; 

// MessageFormat for a NORMAL line in the parsed netflow file 


private static final MessageFormat mfNorm = new MessageFormat ( 
"{O}, {1}, {2}, {3}, {4}, {5}: {6}, {7} 2(83"); 





// MessageFormat for an ABNORMAL (multiple egress) line in the 
parsed netflow file // 
private static final MessageFormat mfManyEgress = new 
MessageFormat ( 














"{O}, {1}, {2}, {3}, {4}, {5}: {6}, {7} "5 


NetflowValidator (String parsedNetflowFilename, String SRADir, 
NetworkConfig network) throws IOException { 
netflowFile = new File (parsedNetflowFilename) ; 
sraDatabase = new SRADatabase (network, SRADir); 











} 


// returns a list of the egress routers 
private String[] parseMultipleEgress (String multEgress) { 
ArrayList<String> egressRouters = new ArrayList<String>(); 














String[] parts = Re wae 
for (int i = 0; i < parts.length; +) : 
String[] smallerParts = Seat. jolGn ks cee Quake Be 
egressRouters. De eee oe 


La 





} 

String[] result = new String[egressRouters.size()]; 
result = egressRouters.toArray (result); 

return result; 


} 


// T£ return value has length 9 => normal 
// else abnormal (multiple egresses) 

// on error return null 

private Object[] parseLine(String line) { 
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try { 














if (line.indexOf ("UNKNOWN") != -1) { 
return null; 

} else if (line.indexOf('%S') != -1) { 
Object[] parts = mfManyEgress.parse(line); 
return parts; 

} else { 
Object [] parts = mfNorm.parse(line); 
return parts; 








} 
} catch (ParseException e) { 

System.out.printin 

("There was an error parsing the line: " + line); 

e.printStackTrace(); 








} 


return null; 


} 


// validate for multiple egresses 

private boolean validate(String srcip, String srcport, String 
dstip, String dstport, String protocol, String ingress, String[] 
egresses) throws RouterConfigNotPresentException, 
PathNotPossibleException { 











for (int i = 0; i < egresses.length; i++) { 
if (validate(srcip, srcport, dstip, dstport, 
protocol, ingress, egresses[i]) == true) { 


return true; 


} 


return false; 


} 


// validate a single instance 

private boolean validate(String srcip, String srcport, String 
dstip, String dstport, String protocol, String ingress, String egress) 
throws RouterConfigNotPresentException, PathNotPossibleException { 











PacketSet ps = null; 











try { 
ps = sraDatabase.getPacketSet (ingress, egress); 
} catch (PathNotPossibleException e) { 
throw e; 
} 
if (ps == null) { 
throw new RouterConfigNotPresentException(); 
} 
// mask of null means single IP address - no range 
Range src = ps.convertIPtoIntegerRange(srcip, null); 














Range dst = ps.convertIPtoIntegerRange(dstip, null); 





int sourcePort = Integer.parselInt (srcport) ; 
int destPort = Integer.parselInt (dstport); 
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int proto = Integer.parselInt (protocol); 


//Conduct the validation test 
for (int i = 0; i < ps.tupleArray.size(); itt) { 
Tuple t = (Tuple) ps.tupleArray.get (i); 
if (src.lower < t.sourceIP.lower 
src.upper > t.sourcelIP.upper 
dst.lower < t.destinationIP.lower 
dst.upper > t.destinationIP.upper 
sourcePort < t.sourcePort.lower 
sourcePort > t.sourcePort.upper 
destPort < t.destinationPort.lower 
destPort > t.destinationPort.upper 
proto < t.protocol.lower 
proto > t.protocol.upper) { 
continue; 











} 

return true; 
} 
return false; 


} 


// opens netflow file and "validates" every line 
public void startValidation() { 
BufferedReader br = null; 











try { 





br = new BufferedReader (new InputStreamReader (new 
FileInputStream ( 
netflowFile))); 

} catch (FileNotFoundException e) { 
e.printStackTrace(); 
System.exit (-1); 

















try { 
String netflowLine = null; 
int errorCounterRCNP = 0; 
int errorCounterPNP = 0; 
int totalErrors = 0; 
int notValidCounter = 0; 
int validCounter = 0; 
int totalCounter = 1; 
int skippedCounter = 0; 
int totalTested = 0; 
while ((netflowLine = br.readLine()) != null) { 











Object[] fields = parseLine (netflowLine) ; 


if (fields == null) { 
skippedCounter+t+; 
continue; 


String srcip = (String) fields[0]; 
String srcport = (String) fields[1]; 
String dstip = (String) fields[2]; 
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String dstport = (String) fields[4]; 
String protocol = (String) fields[4]; 
String ingress = (String) fields[5]; 
try { 

if (fields.length == 8) { 





// multiple egresses 
String[] egresses = parseMultipleEgress((String) fields[7]); 
boolean result = validate(srcip, srcport, dstip, dstport, 
protocol, ingress, egresses); 

















if (result == false) { 
notValidCounter++; 
System.out.print ("Validation failed on line " 
+ (totalCounter) + " of netflow input: "); 











System.out.printin(netflowLine) ; 


} 





} else { 
// Single egress 
String egress = (String) fields[7]; 
boolean result = validate(srcip, srcport, dstip, 


dstport, protocol, ingress, egress); 








if (result == false) { 
notValidCounter++; 
System.out.print ("Validation failed on line " 
+ (totalCounter) + " of netflow input: "); 








System.out.printin(netflowLine) ; 


} else { 
validCounter+tt; 
System.out.printin("!!!t!rrritt! Line 
+ totalCounter + " of netflow is valid !!/!?}t!tlt™); 


} 
} 
} catch (RouterConfigNotPresentException rcnpe) { 
System.out.print ("Error occured on line " + (totalCounter) 
+ " of netflow input - no router config present:"); 
System.out.printin(netflowLine) ; 
errorCounterRCNP+tt; 
} catch (PathNotPossibleException pnpe) { 
errorCounterPNPt+; 














totalCountertt+; 
} 


DecimalFormat df = new DecimalFormat ("##0.0000"); 





totalErrors = (errorCounterRCNP + errorCounterPNP + 
skippedCounter) ; 








totalTested = (totalCounter - totalErrors); 





double percentValid = ((validCounter / totalTested) * 100); 
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double 
doubl 


percentNotValid = ((notValidCounter / totalTested) * 100); 





double 


percentTested = ((totalTested / totalCounter) * 100); 


roundedPV = new 


Double (df.format (percentValid) ) .doubleValue(); 


double roundedPNV = new 


Double (df. format (percentNotValid) ) .doubleValue(); 








double roundedPT = new 


Double (df.format (percentTested) ).doubleValue(); 





















































System.out.printin 
«™ REPORT m3 
System.out.printin("Total passed validation: " + validCounter 

+ "is " + roundedPV + "% of lines tested"); 
System.out.printin("Total failed validation: " + notValidCounter 

+ "is " + roundedPNV + "% of lines tested"); 
System.out.printin("Total lines processed: " + totalCounter) ; 
System.out.printin("Total processing errors encountered: " 

+ totalErrors + "\n" 


System. 


System. 











+ "\t" + errorCounterRCNP 

+ " due to missing router config\n" 

+ "\t" + errorCounterPNP 

+ " due to no path found\n" 

+ "\t" + skippedCounter 

+ " were skipped for missing a field value") 
out.printin("Total lines tested: " totalTested + "is " 
+ roundedPT + "% of total processed"); 

















out.printin 








"); 
} catch (IOException e) { 
e.printStackTrace(); 
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